[Chapter 38] 38.2 Configuration Lines
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T22:47:33Z

#

| Chapter 38 Rule-Set Testing with -bt |

## 38.2 Configuration Lines

Selected configuration file lines can be entered in rule-testing mode. They will behave just as they do when being read from the configuration file. Currently (as of V8.8 sendmail), three configuration commands are honored:

`#`

  Commands that begin with a `#` are treated as comments and ignored. Blank lines are also ignored.

`D`

  The `D` configuration command (see Section 31.3, "Configuration File Definitions") is used to define a macro. Both single-character and multicharacter macro names may be used.

`C`

  The `C` configuration command (see Section 32.1, "Class Configuration Commands") is used to add a value to a class. Both single-character and multicharacter class names may be used.

The `#` may begin a line. The other two configuration commands in rule-testing mode must begin with a dot. Failure to use a dot will produce this error message:

>     No address!

The use of any character other than the two listed will produce this error:

>     Unknown "." command .bad command here

To get a usage message, just type a dot:

>     > .
>     Usage: .[DC]macro value(s)

### 38.2.1 Define a Macro with .D

The `.D` rule testing command is used to define a macro. One use for this command might be to modify a rule that depends on the `$&` prefix (see Section 31.5.3, "Use Value as Is with $&"). For example, consider the rule in rule set 0 that is intended is to deliver a local user's address via the `local` delivery agent:

>     R$+      $#local $@ $&X $: $1

If `$X` has a value, this rule returns it as the host (the `$@`) part of a rule set 0 triple. If `$X` lacks a value, the host part is empty. This technique is useful because the `$@` part with the `local` delivery agent is used to implement plussed users (see Section 24.4.3, "Plussed Users").

This scheme can be tested in rule-testing mode by first specifying a local user with `$X` undefined:

>     > 0 bob
>     rewrite: ruleset   0   input: bob
>     rewrite: ruleset   0 returns: $# local $@ $: bob

This form of rule testing and the output produced are described in detail in Section 38.6. Here it is important only to note that the host part of the triple (`the $@` part) is empty.

Now use the `.D` command to give `$X` the value `home`:

>     > .DXhome

Now test those rules again:

>     > 0 bob
>     rewrite: ruleset   0   input: bob
>     rewrite: ruleset   0 returns: $# local $@ home $: bob

This time the host part of the triple (`the $@` part) has the value `host` as intended.

The `.D` command can also be used to redefine the value of existing macros. It may not, however, be used to redefine macros used in rules (except for `$&`), because macros are expanded as rules are read from the configuration file. (See Section 31.5.2, "When Is a Macro Expanded?" and Section 38.3.1; describes how to view macro values in rule-testing mode.)

Internally, the `.D` command calls three routines, two of which you can watch. First it calls macid() to translate a macro name into an integer index. This can be watched with the `-d35.14` debugging switch (see Section 37.5.121, -d35.14). Second, it calls translate_dollars() to convert the `$x` form into its internal form. This step cannot be watched. Finally, it calls define() to actually define the macro. This step can be watched with the `-d35.9` debugging switch (see Section 37.5.120, -d35.9).

### 38.2.2 Add to a Class with .C

The `.C` rule testing command is used to add a member to a class. If the class does not exist, it is created. One possible use for this command would be to test whether adding a member to `$=w` will have the effect you desire. For example, suppose that a new alias called `mailhub` has been created for the local host. In the following, we test sendmail to see whether it will detect that new name as local:

>     > 3,0 bob@mailhub
>     rewrite: ruleset   3   input: bob @ mailhub
>     rewrite: ruleset   3 returns: bob < @ mailhub >
>     rewrite: ruleset   0   input: bob < @ mailhub >
>     rewrite: ruleset   0 returns: $# smtp $@ mailhub $: bob < @ mailhub

This form of rule testing and the output that is produced are described in detail in Section 38.6. Here, merely note that the `smtp` delivery agent was selected, suggesting that mailhub was not automatically recognized as local.

One way to fix this is to add mailhub to the class `$=w` (see Section 32.5.8, $=w). In rule-testing mode this can be done by using the `.C` command:

>     > .Cw mailhub

Now feed sendmail the same rules and address as before to see whether this fixed the problem:

>     > 3,0 bob@mailhub
>     rewrite: ruleset   3   input: bob @ mailhub
>     rewrite: ruleset   3 returns: bob < @ mailhub . >
>     rewrite: ruleset   0   input: bob < @ mailhub . >
>     rewrite: ruleset   0 returns: $# local $: bob

Success! Adding mailhub to the class `$=w` fixed the problem. You could now make that change permanent by editing the configuration file or by adding the name to the sendmail.cw file (see Section 19.6.26, FEATURE(use-cw-file)).

Another use for `.C` would include trying out masquerading for a subdomain. (See Section 19.6.12, FEATURE(limited-masquerade). See also Section 38.3.2 for a way to print the members of a class while in rule-testing mode.)

Internally, the `.C` command calls four routines, but you can watch only three. First it calls macid() to translate a macro name into an integer index. This can be watched with the `-d35.14` debugging switch (see Section 37.5.121). Second, it calls translate_dollars() to convert the `$=x` form into its internal form. This step cannot be watched. Third, it calls expand() to expand any macros that appear in the list of words. This may be watched with the `-d35.24` debugging switch (see Section 37.5.122, -d35.24). Finally, for each word that it adds to the class, it calls setclass(), which can be watched with the `-d37.8` debugging switch (see Section 37.5.127, -d37.8).

38.1 Overview |  | 38.3 Dump a Macro